500 MB Nyheder Direkte fra Internet 6/500 MB nyheder direkte fra internet CD 6.iso/start/zipped/dos/novell/pnwtid.exe/14935.TXT

Text File | 1994-07-27 | 35KB | 737 lines

              NOVELL TECHNICAL INFORMATION DOCUMENT

TITLE:              Memory - Conflicts, Usage, Optimization
DOCUMENT ID:        TID014935
DOCUMENT REVISION:  A
DATE:               13JUL94
ALERT STATUS:       Yellow
INFORMATION TYPE:   Issue
README FOR:         NA

NOVELL PRODUCT and VERSION:
PERSONAL NetWare 1.0

ABSTRACT:

This document covers memory issues and concerns that may arise
when using Personal NetWare.  Topics include memory conflicts,
usage, and optimization.

----------------------------------------------------------------
DISCLAIMER
THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO
NOVELL.  NOVELL MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY
THIS INFORMATION.  HOWEVER, THE INFORMATION PROVIDED IN THIS
DOCUMENT IS FOR YOUR INFORMATION ONLY.  NOVELL MAKES NO EXPLICIT
OR IMPLIED CLAIMS TO THE VALIDITY OF THIS INFORMATION.
----------------------------------------------------------------

ISSUE

This document is broken into the following five sections:

1.   How to resolve memory conflicts
2.   How Personal NetWare install/setup options affect memory
3.   How specific drivers use memory (excluding SERVER and VLM)
4.   How VLM.EXE uses memory
5.   How SERVER.EXE uses memory

Each section includes suggestions on optimizing your system.


HOW TO RESOLVE MEMORY CONFLICTS

Memory conflicts can cause lockup, spontaneous rebooting, failure
to communicate over the network, failure of floppy drives and
other devices, and various error messages, especially "Protection
Errors" or "Protection Faults".  Even if you do not suspect a
memory conflict, the information in this section can be used for
general trouble-shooting.

Some memory conflicts arise when hardware tries to use an upper
memory address that is being used by other hardware or software.
Many network cards use upper memory, calling it "shared ram" or a
"MEM address".  To resolve memory conflicts involving hardware,
try the following:

1.   If the memory conflict is between 2 hardware devices, you
must change one device's configuration to use a different upper
memory address.  Consult your hardware documentation for more
information on how to accomplish this.

2.   Even if you only have one hardware device using upper
memory, you will probably run into conflicts with software that
has been "highloaded" by a memory manager.  Use an exclude switch
on your memory manager line (in the CONFIG.SYS file) to tell it
not to let software use a specific area of upper memory.  Common
memory managers that handle upper memory include EMM386.EXE,
QEMM386.SYS, 386MAX, and the memory manager built into Windows.
Consult your DOS or third-party memory manager documentation for
information on excluding upper memory ranges.  Consult your
network card documentation to determine what addresses to
exclude.

Some memory conflicts do not involve hardware.  They may occur
when two software programs, often TSRs or device drivers, attempt
to use the same area of memory.  If you think this is happening,
try the following:

1.   Make your configuration as simple as possible.  This can be
accomplished by placing the word REM at the beginning of any line
in your CONFIG.SYS or AUTOEXEC.BAT files which isn't absolutely
necessary for the program which is having trouble.  REM will
cause the line to be ignored.  If this approach fixes the
problem, put the lines back one at a time to determine which item
in your configuration is involved with the conflict.

2.   Alter the order or location in which you load your drivers
and TSRs.  This is especially helpful if you have some idea which
drivers are involved.  Sometimes programs only conflict when
loaded in a certain order.  Keep in mind, however, some drivers
MUST be loaded in a particular order.

3.   If you are loading drivers into upper memory, try putting
them in conventional memory instead.  Upper memory was originally
intended for use by hardware only. Occasionally software can
cause problems when it uses upper memory.  Along these same
lines, if you are using a memory manager that gives you access to
upper memory blocks, such as EMM386.EXE or QEMM386, you could try
using a memory manager that only manages extended memory, such as
HIMEM.SYS or HIDOS.SYS.  This may not be desirable for the long
run, but may give you or a technical analyst clues about the
problem.


HOW PERSONAL NETWARE INSTALL/SETUP OPTIONS AFFECT MEMORY

Using NWCACHE

NWCACHE will greatly speed up your access to local drives.  On a
server, "speeding up the local drives" means that other clients
who map to that server's drives will also see a speed increase.
Discussion of the memory implications of loading NWCACHE will
occur later in this document, so we may go into extra detail.

Memory Management

If the Personal NetWare install program detects upper RAM
provided by a memory manager on your machine, it will
automatically set up your system to load most of the Personal
NetWare drivers into upper memory.


Server Types

Install will ask you about the types of servers you will be
connecting to.  The number and types of servers you connect to
will not significantly affect memory usage on your machine.
However, you will operate more quickly if you only choose those
types of servers which you actually will be accessing.  These
server types correspond to what NETWARE PROTOCOLS you will be
loading.  Possible protocols are BIND (bindery servers, NetWare
2.x and 3.x), NDS (Novell Directory Services, NetWare 4.x) and
PNW (Personal NetWare).  Your NET.CFG will be set up to reflect
your choice.

Sharing Resources (making your machine a "server")

Install will give you the option to share your machine's
resources.  Choosing to do this will result in SERVER.EXE loading
into memory on your machine.  This can use anywhere from 30 to
100 Kilobytes of memory on your machine, depending on how you
configure the server.  Loading this if you do not intend to use
it will waste memory.  You can add it later if you change your
mind.  More details on memory and server configuration will be
given later in this document.

Using DPMS

DPMS is a memory specification that allows TSRs and device
drivers to load portions of their code into extended memory, and
execute there in protected mode.  To use this, your machine must
be a 286 or higher, with extended memory.  You must also be
loading a memory manager which can make extended memory available
as XMS memory.  Using DPMS will save you significant amounts of
memory if you will be using NWCACHE or if you have chosen to
share your machine's resources (being a "server") on the network.
Also, if you are using Novell DOS 7, DPMS will save you memory
with NWCDEX.EXE, DELWATCH.EXE, and Stacker disk compression.

Enabling the SNMP Agent

The SNMP agent allows remote machines to gather network
information from your machine.  This requires a significant
amount of memory and is usually only necessary if the
administrator of a Novell 3.x or 4.x network needs to gather
information from your machine with special utilities.  Personal
NetWare does not need SNMP for any of its own functions.

Enabling the Network Management Responder (NMR)

The NMR network management module will require less than 1
Kilobyte of conventional memory on a machine with XMS.  It
requires 2.5 Kilobytes on a machine without XMS.  It will allow
you to use management features such as the Personal NetWare
Diagnostics, which can analyze your network connections and
communications.  If you have already diagnosed any communication
problems you experienced in setting up the network, you may want
to turn this feature off, to save memory.


HOW SPECIFIC DRIVERS USE MEMORY (EXCLUDING SERVER AND VLM)

Often, network drivers require more memory to load (initialize)

than they need to operate after initializing.  Knowing this can
be especially important when trying to load drivers into upper
memory blocks, as space in upper memory is often very limited.
In addition, some of the Personal NetWare drivers have options
that affect which types of memory the program loads into.  The
commands that load the Personal NetWare drivers are usually found
in the STARTNET.BAT file in the NWCLIENT subdirectory.

LSL.COM

In its default configuration, LSL.COM requires approximately 18
to 22 Kilobytes of contiguous memory to initialize; then it
reduces to 5 1/2 Kilobytes.  It can be loaded into upper memory
by DOS or third-party memory managers.  However, in rare
instances LSL has not been able to perform all of its functions
when placed in upper memory.  If you have trouble with LSL in
upper memory, try loading it in conventional.

IPXODI.COM

In its default configuration, IPXODI.COM requires 34 to 38
Kilobytes of contiguous memory to initialize; then it reduces to
16 Kilobytes.  It can be loaded into upper memory by DOS or
third-party memory managers.

IPXODI.COM provides both IPX and SPX services.  If you do not
need SPX services, load IPXODI with the A parameter (LH IPXODI
A).  This will save memory.  However, you may have applications
which require SPX.  Generally, these applications will tell you
they require SPX either in documentation or via an error message
if you do not have SPX active.

Using the "A" parameter also disables a diagnostic responder.
This is used by the Network Management Responder (NMR.VLM).
This, in turn, is used by Personal NetWare Diagnostics.  However,
you may not need these Diagnostics unless you experience
communication problems.  If you wish to disable the diagnostic
responder but leave SPX active, load IPXODI with a "D" parameter.
There is no way to disable SPX but leave the diagnostic
responder.

NWCACHE without DPMS support

NWCACHE (the program itself) will use a minimum of 26 kilobytes
of memory.  If you use EMS memory for the cache buffer, it will
not require any more than this.  If you use XMS for the cache
buffer, the NWCACHE program will require an additional 3 1/2 K
for every 1 megabyte of cache buffer.  For example, a 5 megabyte
cache in XMS memory would cause the NWCACHE program code to
occupy approximately 42 kilobytes of memory.  The advantage of
using EMS memory will not be significant enough to justify the
creation of a EMS page frame just for the purposes of NWCACHE, as
an EMS page frame uses 64K of upper memory.

NWCACHE with DPMS Support

If DPMS is enabled, NWCACHE will take approximately 21 kilobytes
of space, regardless of what type of memory the cache buffer is
given, and regardless of the size of the cache buffer.


NWCACHE (general)

Initialization and post-initialization sizes are not
significantly different with NWCACHE.  It will automatically load
all or part of its code into available upper memory.  It may
leave a 16 Kilobyte buffer in conventional memory.  This can be
reduced in size or forced into upper or EMS memory (if they are
available) by using /BU or /BE on the line that loads NWCache.
Type NWCACHE/? at the DOS command line for more information on
these options.


HOW VLM.EXE USES MEMORY

The Virtual Loadable Modules (VLMs) require approximately 100
Kilobytes of memory.  However, if your machine has extended
memory managed to the XMS or EMS standards, 45 Kilobytes of this
will automatically be placed into such memory.  If VLM.EXE is not
automatically using your available XMS or EMS, try using /MX or
/ME (respectively) to specify which memory to use.  Make sure you
are not using a /MC, as this forces VLM.EXE to remain in
conventional memory.  Forcing VLM to remain in conventional
should only be done if memory usage is not important and greater
network performance (speed) is needed.  Type VLM /? at the dos
command line for more information on VLM options.

In addition to using XMS or EMS memory, up to 50 kilobytes of the
remaining code will automatically be placed in upper memory if
there is enough space.  Approximately 5 kilobytes remain in
conventional unless you specifically use your memory manager to
load it into upper memory.  Keep in mind, however, that your
network performance may decrease when putting all of VLM.EXE into
upper memory.  This is not unique to VLM.EXE.  It is due to how
upper memory is accessed.  Virtually any program will operate
slower in upper memory than it will in conventional memory.

Initializing the entire 55 kilobyte portion of VLM into one
contiguous upper memory area requires 70 to 74 kilobytes of
memory.  However, because VLM splits its own code into several
pieces, you may not need one contiguous area of that size.

You can reduce the normal size of VLM.EXE by not loading some of
its components.  There are many "VLMs"--small modules that match
the filespec "*.VLM".  If you do not attach to NetWare versions
2.x, 3.x, or 4.x, do not load BIND.VLM, NDS.VLM, NETX.VLM,
SECURITY.VLM, and RSA.VLM.  The best way to prevent these from
loading is to edit the NET.CFG file, and in the "NetWare DOS
Requester" section, insert lines which read "EXCLUDE VLM =
BIND.VLM", etc.  If you do not load SECURITY.VLM, you may need to
add the line "SIGNATURE LEVEL = 0" to the NET.CFG file as well,
to keep VLM.EXE from returning an error.  Another way to prevent
certain VLMs from loading is to rename them (ie rename BIND.VLM
to BIND.VLM).

If your machine will never be printing to a network printer, you
can also omit loading PRINT.VLM.  You will still be able to print
to a local printer.  "Local printer" means a printer that is
attached to your machine and has not been designated as a shared
printer.  In other words, you will not be able to print to a
printer that is shared if you do not load PRINT.VLM--even if it
is physically attached to your machine.

Another change which causes VLM to use less memory is to add
"RESPONDER = OFF" to the NET.CFG (also in the NetWare DOS
Redirector section).  This will save a little memory, but your
machine will no longer respond when other stations use NET ULIST.

There is a debugging tool built into VLM which may help you
determine how much memory different VLMs use, and whether you are
using certain ones.  VLM /D displays this diagnostic information.
It takes more than one page, so you may want to send it to a
file, a printer, or to MORE if you want it to pause on the screen
after each page.  Examples of commands to accomplish these are,
respectively:

VLM /D > C:\VLM.MEM
VLM /D > LPT1
VLM /D | MORE

The diagnostic information is quite complex, and most of it does
not fall within the scope of this document.  However, there are a
few pieces of the information which may be useful.  Here is an
excerpt from the VLM /D display (the right most column of the
display has been cut off in order to fit this page.  It is not
relevant to our needs):

VLM diagnostic information             Address        Memory Sizes
NAME     ID   Flag Func Maps Call TSeg GSeg Low  High  TSize GSize
-------- ---- ---- ---- ---- ---- ---- ---- ---- ----  ----- -----
VLM      0001 A000 0005 0000 CE70 E5C2 09AF FFFF 0000   4912 0
CONN     0010 B000 0011 0000 0282 0656 071A FFFF FFFF   3136 384
IPXNCP   0021 B000 000B 0000 0404 0732 084F FFFF FFFF   4560 3328
TRAN     0020 E000 000B 0001 4379 0732 084F FFFF FFFF    285 208
SECURITY 0061 A000 0005 007B 007A E6E6 091F 0000 0000   4192 0
NDS      0032 A000 0010 02E7 03AE E6E6 091F 1060 0000   5952 896
PNW      0033 A000 0010 0089 0092 E6E6 0957 27A0 0000   5680 2528
BIND     0031 A000 0010 01C2 0055 E6E6 09F5 3DD0 0000   2992 448
NWP      0030 A000 0011 025F 00F6 E6E6 0A11 4980 0000   2960 1824
FIO      0041 A000 000B 0D7E 2473 E6E6 0A83 5510 0000   6848 11600
GENERAL  0043 A000 000A 0413 0416 E6E6 0D58 6FD0 0000   1744 624
REDIR    0040 A000 0009 0FB4 1DCD E6E6 0D7F 76A0 0000   9520 2400
PRINT    0042 A000 000F 0519 0560 E6E6 0E15 9BD0 0000   3936 3328
NETX     0050 A000 0007 0559 089C E6E6 0EE5 AB30 0000   8992 4016
AUTO     0060 A000 0006 0082 007F E6E6 0FE0 CE50 0000   2256 592
Total                                                  67680 31968
Maximum                                                 9520 11600

We will refer to columns: Name; Flag; Call; TSize; GSize.

NAME - The left column lists the VLM name (ie REDIR corresponds
to REDIR.VLM).

FLAG - The Flag column indicates (among other things) whether or
not the component is loaded.  Anything other than 0 (or 0000)
indicates that the specified VLM is loaded.  Most of the time, if
a VLM is not loaded, it will not appear on this list at all.

CALL - The number of times (in hexadecimal) this particular VLM
has been called.  This may help you identify a VLM which you
don't actually need to load.  Keep in mind, however, that just
loading VLM.EXE, as well as using VLM /D makes calls to the
individual modules.  So even modules you don't really need will
still show they are being used.  However, if you have been using

the network for over an hour, and you still notice a particular
VLM which has been used less that most the others, look it up in
the documentation to determine its purpose.

TSIZE - This refers to "Transient Size" (in decimal).  As a
GENERAL rule, the transient code is placed in XMS (or EMS) memory
and is moved (hence the label "transient") to conventional or
upper when it is to be executed.  The total amount of transient
code is listed near the bottom, followed by a number referred to
as MAXIMUM.  This corresponds to the largest single piece of
transient code.  Swap space of this amount is established by
VLM.EXE in upper or conventional memory.

GSIZE - This refers to VLM code (in decimal) which does not get
moved around.  It always remains in upper and/or conventional
memory.


HOW SERVER.EXE USES MEMORY

SERVER.EXE can be configured to use anywhere from 30 to over 100
Kilobytes of memory.  The exact amount will depend upon the
configuration.  You can load SERVER.EXE into upper memory with a
DOS or third-party memory manager.  Regardless of how small you
set your server configuration, SERVER.EXE will require at least
80 to 84 Kilobytes of space to initialize.  This means that if
you do not have at least one contiguous upper memory area of
approximately 84 Kilobytes at the time SERVER loads, you will not
be able load it into upper memory.  This is true regardless of
whether or not DPMS support has been loaded.  If you configure
server to use over 84 kilobytes, the memory it needs to
initialize will not be significantly different from the
post-initialization size.

Tips for Loading SERVER.EXE into Upper Memory

If you are having trouble loading SERVER.EXE into upper memory,
it would most likely be because you do not have a contiguous area
of upper memory large enough for server to initialize.  If your
server is configured to use more than 80 Kilobytes, try reducing
the configuration settings to bring the size just below 80
Kilobytes.
You may be able to change the size of your upper memory areas by
altering your hardware or software.  Following are some possible
ways of increasing your available upper memory areas.

1.   Areas of upper memory used by hardware tend to reduce and
divide the space available for loading software.  You may be able
to increase the size of your largest available upper memory area
by setting your hardware to their lowest or highest settings.
For example, a network card which uses upper memory may cut your
upper memory in half, giving you two small areas instead of one
large one. Setting the card to use the low end (around C800 or
CC00) or the high end (E000 or above) will help prevent this.

2.   If your memory manager is UNNECESSARILY establishing a Page
Frame for expanded memory, also referred to as EMS memory or LIM
memory, you will gain 64 kilobytes more upper memory by turning
that feature off.  Consult your software applications'
documentation to determine if you need EMS memory.  Consult your
DOS or third-party memory manager documentation for instructions

on turning off EMS memory.  Some Personal NetWare drivers will
OPTIONALLY use EMS memory.  However, those drivers will use XMS
(extended) memory just as efficiently if you have Novell's DPMS
support loaded.

3.   You may wish to let your smaller drivers reside in
conventional memory in order to have enough upper memory for
server to initialize there.  In other words, you may be able to
gain a lot by giving up a little.

Using DPMS

To reduce the amount of memory SERVER.EXE takes, you can put
approximately 20 Kilobytes of code into XMS memory by using DPMS.
This will occur automatically as long as DPMS.EXE is loading
somewhere before SERVER.EXE.

If DPMS is loaded, the estimate of Server Size given in the
SERVER CONFIGURATION section of NET ADMIN will not include the
amount of code going into DPMS.  The amount it specifies will be
the amount that must remain in either conventional or upper
memory.

Automatic Configuration of the Server

To get good results from the Automatic Configuration feature, you
MUST go into the advanced settings and select an accurate number
of connections.  The number of connections should usually be set
to the number of machines you plan to have in the workgroup,
(including your own) plus two.  This can be reduced, however, if
only a portion of the users in the workgroup will be accessing
your server.  For example, if your machine is a server but is not
the server generally used for file or print sharing, you probably
won't have as many users trying to connect to your machine.

When you run the Automatic Configuration for the server, the
system checks the number of connections you have selected in
Advanced Settings and bases the number of Client Tasks upon this.
Client tasks will be set at a certain multiple of your
connections.  This multiple will depend on what choice was made
for automatic configuration.  If MINIMUM MEMORY was chosen, then
the multiple will be 2 Client Tasks per connection.  If BALANCED
was chosen, then the multiple will be 3 Client Tasks per
connection.  If MAXIMUM PERFORMANCE was chosen, then the multiple
will be 5 Client Tasks per connection. .

In addition to client tasks, the automatic configuration will
also alter your DIRECTORY BUFFERS, PRINT BUFFER SIZE, NUMBER OF
RECEIVE BUFFERS, RECEIVE BUFFER SIZE, NUMBER OF I/O BUFFERS, and
I/O buffer size multiplier.  The values it selects will depend on
which type of automatic configuration you select.  In other
words, changing the number of connections will not affect the
values of those fields.  SHARED DIRECTORIES, SHARED PRINTERS,
CONNECTIONS, and SERVICE EXTENSIONS are not altered by the
automatic configuration.

Please note that automatic configuration is not an on-going
process.  If you wish to use this feature, you should re-select
it anytime you change the number of CONNECTIONS, even if you are
not selecting a different type of automatic configuration.  Do
not be concerned if you have chosen one type of automatic

configuration and subsequently you notice it listed differently.
Because it is not an on-going process, it will not change your
configuration unless you select it yourself.

Advanced Settings

Sometimes lowering your configuration is necessary because you
need more memory for other things or because your current
settings may cause SERVER.EXE to exceed its maximum allowable
size.  Following are some tips for reducing server size through
the settings accessible in "Advanced Settings...".

To access the server configuration, you must first login as a
user who has rights to change the server configuration.  Usually
the SUPERVISOR or anyone designated as a WORKGROUP MANAGER has
sufficient rights.  However, sometimes only the owner of the
server has the needed rights.  Then, issue the command NET ADMIN.
Select the server you wish to configure and press ENTER.  Among
other things, the user who is the "owner" of the server will be
displayed.  Write down the "Future server memory size" so you can
compare after making changes.  Choose "Advanced Settings...."

SHARED DIRECTORIES - Make sure this is not higher than the number
of shared directories you need to create ON THIS MACHINE.  The
"First Time SETUP" usually creates one for each partition on your
hard drive.  You may set up more if you wish.  If this server is
only sharing a printer, set this to 0.  This will cause the File
Sharing Loadable Module to be disabled, which will greatly reduce
server size.

     NOTE:     Once the module is disabled, you cannot access the
"Shared directories" field until you enable it in the Loadable
Modules section (which will be discussed in a later section).

SHARED PRINTERS - Make sure this is not higher than the number of
printers ON THIS MACHINE which will be shared on the network.  If
none, enter 0.  Reductions to this number save the memory that
print buffers would use.  Setting it at 0 causes the Print
Sharing Loadable Module to be disabled, saving you even more.

     NOTE:     Once you save the setting at 0, you can only gain
access to the field by enabling the Print Sharing Loadable
Module.

CONNECTIONS - Proper setting of Connections is discussed above in
the "Automatic Configuration" section.

CLIENT TASKS - Reducing client tasks will not save you much
memory.  In addition, reducing them may cause slowness or errors
while running applications from a server.  So don't skimp on this
setting.  Some general rules for client tasks include:  (A) They
should be set to AT LEAST 2 client tasks per connection.  (B) For
networks where the clients run standard DOS applications and do
not multi-task or task-switch, you probably won't have to set
more than 5 client tasks per connection.  (C) For networks
supporting large database programs or running Windows or Windows
applications over a network, you may need to set client tasks as
high as 10 or more per connection.  Note that the setting in the
server configuration is not "per connection".  If you have 6
connections set and want 5 client tasks per connection, set the
Client Tasks figure to 30.

DIRECTORY BUFFERS - These temporarily store information used to
get directory lists and access files over the network.  The
default which is set by installation or by the automatic
configuration is usually both adequate for performance and low on
memory usage.  These buffers are used for "dirnext" or "findnext"
functions.

PRINT BUFFER SIZE - One print buffer will be allocated for each
shared printer.  The size will affect the speed at which
SERVER.EXE prints, but will not affect the speed at which
applications send the job to the server.  This is because
Personal NetWare uses an efficient print spooler, which accepts
up to 50 jobs very quickly, regardless of how fast the printer is
actually printing.  In other words, setting this at a minimum
will save memory without causing anyone's machine to make them
wait extra time for their application to send the print job.

NO OF RECEIVE BUFFERS - Data coming to and from the server is
stored in these buffers.  For performance reasons, you will
probably want the receive buffers to at least equal the number of
machines on the network.  However, you may be able to set this
even lower if network traffic to this server is relatively low.
This setting will affect memory usage quite a bit.

RECEIVE BUFFER SIZE - Like the number of receive buffers, the
receive buffer size is also a trade off between memory and speed.
For highest efficiency, set receive buffer size to the highest
allowed by the network card.  This will relate to the size of
packets the card can send, not necessarily to the maximum you are
allowed to set in the server configuration.  To find the maximum
your card allows, set the receive buffer size as high as
possible.  Note that you may have to decrease other settings
temporarily to be allowed to set this buffer to its maximum.
Save the configuration and reboot to reload server.  Then go back
to server configuration, advanced settings.  The "CONFIGURED"
column will list the maximum the card allows.  Set the "FUTURE"
column equal to or less than this number.

To save memory, you can decrease the receive buffer size.  This
can save large amounts of space as it will affect the I/O buffer
size as well.  The less the network traffic to this server, the
smaller you can set these buffers without noticing significant
performance degradation.

NUMBER OF IO BUFFERS - An I/O buffer is used as a temporary
storage area to store read/write data from a file.  These buffers
have the best performance when sequential reads and writes are
performed.  The number of IO buffers is the actual number of
buffers allocated in memory.  If you have an external cache
program loaded, it is recommended to set the number of IO buffers
to zero.  An external cache usually has a much higher performance
of caching due to size and specific purpose.

IO BUFFER SIZE MULTIPLIER - The IO buffer size multiplier is the
size, in kilobytes, of each IO buffer.  To determine the total
amount of additional memory required to use IO buffering,
multiply the number of IO buffers by the IO buffer size
multiplier.  For example,  if you have the number of IO buffers
set at 2 and the IO buffer size multiplier set at 4, then you
would have two IO buffers that are 4 kilobytes (or 4096 bytes) in
size.  Total space required for the two buffers would be 8
kilobytes (or 4096 + 4096 = 8192 bytes).

SERVICE EXTENSIONS - If you don't know what service extensions
are, you can probably set them to zero.  If you are supporting
SNMP on this server (discussed earlier) set this to 1.  Also set
this to 1 if you have a Zenith Z-Stor Personal Server.  The first
service extension will cost you less than 1 kilobyte.  Additional
extensions will cost only 48 bytes each.

USE CONFIG.SYS OPEN FILES - Use CONFIG.SYS file handles (the
files= statement used by DOS) unless you have heavy enough use of
the server to require more than 255 files to be open at once.
Extra files will require a significant amount of memory.

NUMBER OF OPEN FILES - This option is only used if the Use
CONFIG.SYS Open Files option is not selected.  It determines how
many files can be opened on the server at one time.  The maximum
this can be set to is 1000 per server.

Loadable Modules

Choosing NOT to load certain loadable modules can also save you
memory.  You can choose to edit the Loadable Modules from the
same screen on which you select Advanced Settings for the server
configuration, discussed above.  Loadable Modules correspond to
portions of SERVER.EXE code.  They do not correspond to the VLMs
(Virtual Loadable Modules) which form the CLIENT portion of the
server/client relationship.  Most modules are only directly
responsible for small amounts of memory.  However, sometimes
disabling a module causes other settings to be ignored, resulting
in additional memory savings.  For instance, without the File
Sharing Module, IO buffers will not be created.  So on some
servers, disabling a particular module may save you a lot of
memory, while on a different server, if may only make a small
difference.

FILE SHARING - If the server is only sharing a printer, do not
load this module.

PRINT SHARING - If the server is not sharing a printer, do not
load this module.

SECURITY - We have observed some unusual behavior on servers with
security disabled.  Due to this, we recommend you leave security
on and use Full Authentication.

FULL AUTHENTICATION - If the FULL AUTHENTICATION module is
loaded, then the system checks the passwords on accounts when
users log in.  If this module is not loaded, no user is prompted
for a password during LOGIN.  FULL AUTHENTICATION should ALWAYS
be checked in this version.
LOCAL AUTHENTICATION - If the LOCAL AUTHENTICATION is loaded, the
users are allowed to login locally only, and cannot access
resources across the network, and remote login is not allowed.
The LOCAL AUTHENTICATION is for future versions of Personal
NetWare, therefore, FULL AUTHENTICATION should ALWAYS be checked
in this version.

POP-UP SCREENS - Normally, the server pops-up warnings concerning
printers that appear off-line, an attempt to reboot the server,
etc.  If you do not want or need this service, you can turn it
off.


REPORTING - This option turns enables the audit and error logs
features of Personal NetWare for this server.  Reporting allows
you to track errors reported by the server, as well as normal
behavior (ie users logging in, servers coming "up" or "down").
The nature of this information makes it either very important or
very unnecessary.

DIAGNOSTICS - This module supports calls made by NET DIAGS (and
the Windows utility "Personal NetWare Diagnostics").  If you
don't use these programs, you can turn this feature off.

CONSOLE - This module supports NET CONSOLE, which allows you to
see who is connected, what files they have open, and allows you
to clear connections.  Note that "clearing connections" is not
something you usually need to worry about.  Personal NetWare will
automatically clear unused connections.  Connections in use will
automatically re-connect even when you have specifically cleared
them.

SALVAGE - This module only applies to Novell DOS 7 users.  If the
server is running Novell DOS's DELWATCH TSR, Salvage will allow
you undelete files over the network.  Without Salvage, you would
have to be at the server itself to undelete files.


ONE FINAL TIP

This is "undocumented" and not supported, but there is another
small piece of code in server which you can disable.  You can
save an additional 192 bytes of memory by loading server with an
L option ("SERVER L").  There are certain database programs (i.e.
DBase, Clipper) that are NetWare aware but use an NCP call
(NetWare Core Protocol) incorrectly.  Server usually accounts for
this, but the L option disables this protection.  If you share a
database or load SHARE with extra locks, do not use this
parameter.

The term "not supported" means you use it at your own risk.  If
it causes a problem, Novell cannot help you solve it, except to
say "don't use that option".  Before calling Novell for technical
support on ANY Personal NetWare problem, you should have SERVER
loaded without the L option, even if it appears to make no
difference.


_Verified by customer
_Verified by Novell

----------------------------------------------------------------
Any trademarks referenced in this document are the property of
their respective owners.  Consult your product manuals for
complete trademark information.
----------------------------------------------------------------